Team Topologies as an organizational pattern language — Part 1

This is a slightly modified transcript of a talk I did at the Vienna Agile Tour 2023 conference. It is split in three parts. The first part introduces the concept of a pattern language and discusses the requirements for a successful IT organization.

If you happen to be Austrian and of a certain age you may remember Fred Sinowatz. He was Austrian chancellor in the early eighties and became quite famous because of the thing he said in a speech in the Austrian parliament in 1983.

“Everything is very complicated”

I was a kid back then but I clearly remember that during the following years his political opponents but also mainstream media used to make fun of him because of this.

This statement was not something you would expect from a politician — you would expect fast decisions and strong opinions. Things have not changes a lot in that respect, I guess.

When I grew older and more interested in politics I remembered that quote and did some research. And I found out that this is what he actually said:

“I know, ladies and gentlemen, that everything is very complicated, just like this world which we live and act in, and the society in which we want to unfold ourselves. Let us therefore have the courage to point out this complexity more than before. Let’s admit that there can’t be perfect solutions for everything and everyone in a pluralistic democracy.”

Well, that sounds a bit different, doesn’t it?

At that time I realised consciously for the first time that most of the things we have to deal with are quite complex and that most of the people have problems accepting this complexity. Besides this, it also seems incredibly difficult to explain that fact.

Working many years in the software industry has not changed my perception and current understanding of many things we have to deal with is more like this:

I have yet to see any problem, however complicated, which, when looked at it in the right way, did not become more complicated. (Poul Anderson)

I just want to discuss one approach that can help us to make sense of some classes of problems in a meaningful way. And this is patterns.

What do I mean with this?

We as human beings crave for sense — it is difficult for us to cope with randomness and unpredictability.

So what constantly happens is that we try to detect familiar patterns that help us with making sense.

There is a huge danger in this approach because we as human beings tend to simplify and have a lot of biases but if we use this strategy consciously we have a very powerful tool at our hands.

Teh term pattern usually is defined as a “general repeatable solution to a commonly occurring problem. Patterns can be used to describe a problem, describe the core aspects of a solution to a problem, and capture the reasoning behind a solution.”

Pattern languages are collections of related patterns that work together to solve a problem in a particular context.

The original concept of a “pattern language” was introduced by architect Christopher Alexander, who used it to describe a set of design solutions for common problems in the building and planning of cities and towns.

It is a beautiful book with many very inspiring patterns — I wish, all modern city planners would read it. Christopher Alexander’s work is deeply humanistic, his work is centred around an idea of “wholesomeness”, an environment that makes us feel whole as a human.

It is no surprise that the concept of a pattern language at that time actually generated considerable interest also in the software architecture community.

We also have pattern languages for software engineering.

The famous Gang of Four (Design Patterns — Elements of reusable Object-Oriented Software) pattern book introduces a pattern language to deal with commonly occurring problems in software engineering. I am sure all of you have heard about Singletons, Observers and factories. If not, you should read this book. I was given the book by my boss in the second week after starting working at my first job as a developer in 1999 and I have to admit was slightly overwhelmed.

As one can imagine these kind of pattern languages can be used in a lot of different problem spaces — I specifically want to discuss about one in the space of organizational design.

But first we need to define what we want to achieve. Organizations have widely differing purposes, so first we are talking about IT organizations and secondly, we are talking about IT organizations that provide some kind of solution to customers. This is still a very generic definition but we have narrowed down our potential area of applicability a bit.

So we are talking more or less about organizations that deliver customer value via software products. Software is everywhere nowadays so still many companies are covered with this kind of scoping.

To be good in delivering software we need to deliver frequently, collect feedback fast and constantly learn from that feedback as people and as organization.

Whatever organizational setup we have in mind must support these capabilities. Otherwise the company just won’t be successful.

There is a lot of empirical data available to show this. Just think about the DORA metrics as described in the book “Accelerate.”

Delivering frequently to collect feedback fast to learn from it could also be framed as achieving a fast flow of changes to our customers. This is what we want to achieve.

Another important aspect we need to consider is that it is our duty to create an organization that is good for us as human beings.

You may call me naive or idealistic but I am convinced that we have a duty to at least try to make our work engaging and satisfying. This involves a clear purpose, rich human interactions and the opportunities to learn and grow.

Most people have at least heard about intrinsic motivation — the motivation that comes from within. The one that keeps us attached to our work and ultimately allows us to be creative and innovative. A good workplace is crucial to foster this intrinsic motivation so even from a purely pragmatic or business perspective, we need to consider these factors if organizations should be successful.

There is a third thing that needs to be considered when we talk about organizations that produce software and that is the coherence of organization and software architecure.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

This is Conway’s Law. In simple words it says that the structure of the organization determines the resulting system architecture. Mel Conway, an US computer scientist, formulated that law in 1967.

There is a famous example from Eric Raymond who says that if you have four independent groups working on a compiler you will get a four pass compiler.

There are many other examples and it is generally accepted that Conways Law holds in a lot of different circumstances.

So if we think about patterns for our organization we also need to have Conways Law in mind. Because if we mess up the organization, we will also have problems with the architecture of our systems.

What this means is also that we can’t leave the design of our organization to HR people alone. We need to bring in our system architecture knowledge if we want to avoid bad consequences in the future.

Two main principles in software architecture are loose coupling and strong cohesion. So what if we design our organization in a way that the architectural properties that we desire will be emerging?

That is possible and the process is called the “Reverse Conway manoeuvre”.

Another problem for us engineers to solve. Ah, so much problems to solve.

Part two describing the “Team First” approach and introducing the first patterns can be found here.